Hello
Just starting out with PagerDuty so we decided to use email integration, with a view to use the API in the future.
We are therefore wondering if there is any way to update incidents using email. Seems like this would not be the case as the traffic is all one way - monitoring -> email -> PagerDuty but thought it worth an ask.
Thanks
Dave
For email, you can map one email type (eg subject containing DOWN) to be a triggering email to create the incident. Then, you can map a different email (eg subject containing UP) to be the resolution email and resolve the incident.
The key here is that in your configuration, you must have a unique deduplication key for the trigger and the same one for the resolve condition. This is required to match the resolution email with the trigger email and resolve the incident.
By default, the deduplication key for email is the subject line. If you can’t get unique subject lines for each email, you’ll need to use event rules and regex to build and set your deduplication key with other email content (headers, subject, body).
Make sense?
Hi Doug,
Thanks for your response.
So if I have understood correctly we would send the following (in the subject) to trigger an incident (both event rules)
“SQL Critical”
and then the following to close the incident
“SQL Normal”
I would add a customer trigger to my second event rule which always closes an incident. What I don’t understand is which incident would it close if there was more than one.
This is how I have my event rules set at present for SQL.
Thanks
Dave
So no luck with this so far.
I also changed the event rule to create an incident but I do not even get an alert now.
The key is that you create the same UNIQUE deduplication key in each rule. Ideally, we’ve got something else like an alert ID, hostname, etc. that we can use to make it unique (hostFoo:Alert123) in the triggering email rule and make it the same in the resolving email rule.
Your first rule should identify the conditions (ALL) needed to match the triggering condition, create the dedup key, have an action to always trigger the incident and route to your service.
Your second rule should identify the conditions (ALL) needed to match the resolving condition, create the same dedup key, have an action to always resolve the incident and route to your service.
Make sure you don’t have “suppress” selected in a rule! Sometimes you need to also ensure the “resolve” rule is higher up than the “trigger” rule as rules are processed top to bottom, first matching rule is processed only.
